許多企業投資於其下一代資料湖，希望大規模地民主化資料，以提供商業見解，並最終做出自動化的明智決策。基於資料湖架構的資料平台具有常見的失敗模式，導致無法大規模實現承諾。為了解決這些失敗模式，我們需要從湖泊或其前身資料倉庫的集中化模式轉移。我們需要轉移到從現代分散式架構中汲取的模式：將領域視為首要考量，應用平台思維來建立自助式資料基礎架構，並將資料視為產品。

Xapo 成立為比特幣服務供應商，並發展成為線上銀行。在此過渡期間，它需要重新評估其軟體資產，並建立架構能力來指導其未來。它從領域驅動設計、團隊拓撲和架構建議流程中汲取想法，以開發架構建議論壇。這導致其軟體交付團隊更緊密地結合，並制定了一致的技術策略。

這是一個已經存在很長一段時間的反模式，但似乎在目前特別盛行。我與 Eric Evans 討論過這件事，我們都注意到它們似乎越來越受歡迎。作為適當領域模型的強力支持者，這並非好事。

受限上下文是領域驅動設計中的核心模式。它是 DDD 策略設計部分的重點，而該部分的重點在於處理大型模型和團隊。DDD 透過將大型模型分為不同的受限上下文，並明確說明它們之間的相互關係，來處理大型模型。

CQRS 代表命令查詢責任隔離。這是我第一次聽 Greg Young 描述的模式。其核心概念是，您可以使用一個不同的模型來更新資訊，而不是您用來讀取資訊的模型。在某些情況下，這種分離可能很有價值，但請注意，對於大多數系統而言，CQRS 會增加風險複雜性。

在我寫作的過程中，我早就打算撰寫一段關於驗證的材料。這是一個導致許多混淆的領域，對於一些運作良好的技術，獲得一些紮實的描述會很好。然而，生活中充滿了許多事情需要寫，遠遠超過時間允許的範圍。

許多電腦系統建置的目的是為了儲存資料，並將資料轉換成對人類有用的資訊。當我們這麼做時，自然會希望這些資訊是一致的。畢竟，一個對事情猶豫不決的電腦系統有何用處？

有許多 值物件 的常見範例，我最喜歡的是 貨幣，而與貨幣密切相關的就是貨幣單位。

上週我在卡加利辦公室，與我們最值得信賴的技術主管之一約翰·科迪巴克 (John Kordyback) 進行了一次愉快的交談。他參與並深入研究了許多旅遊忠誠度軟體系統（例如常客飛行計畫/臥鋪等），我們討論了這些事物的性質，以及如何以更有成效的方式思考它們。

聚合是領域驅動設計中的一種模式。DDD 聚合是一群可以視為單一單位的領域物件。一個範例可能是訂單及其明細項目，這些項目將會是獨立的物件，但將訂單（連同其明細項目）視為單一聚合是有用的。

領域驅動設計是一種軟體開發方法，其開發核心在於編寫一個領域模型，該模型對領域的流程和規則有深入的了解。這個名稱來自埃里克·埃文斯 (Eric Evans) 於 2003 年撰寫的一本書，該書透過一系列模式來描述這種方法。從那時起，一群實務工作者進一步發展了這些想法，衍生出各種其他書籍和訓練課程。這種方法特別適合於複雜的領域，其中需要組織許多經常混亂的邏輯。

我在 QCon 舊金山 參加的有趣演講之一，是由 葛瑞格·楊 針對他在最近的系統中使用的一種特定架構所做的演講。葛瑞格是 領域驅動設計 的忠實擁護者，在這種情況下，它需要與一個必須處理高交易率並向大量使用者提供資料的系統一起使用。我發現他的設計有許多有趣的地方，尤其是他使用 事件溯源 的方式，但對於這篇文章，我只想探討一個面向，也就是我稱之為熱切讀取衍生。

Eric Evans 在他傑出的著作 領域驅動設計 中，建立了您可能會遇到的不同種類領域物件的分類。

「《戰爭與和平》是一本很棒的書。」

「讓我看看... 可惜這本書的封面破破爛爛的。」

這兩句話都使用了「書」這個字。我們每天都會看到這種組合，卻不會注意到「書」這個字在每句話中的意思完全不同。

Eric Evans 在 領域驅動設計 中使用「無所不在的語言」這個術語，表示開發人員和使用者之間建立共同、嚴謹語言的實務。這種語言應以軟體中使用的 領域模型 為基礎，因此需要嚴謹，因為軟體無法很好地應對模糊性。

在編程時，我常常發現將事物表示為複合很有用。2D 座標包含 x 值和 y 值。金額包含數字和貨幣。日期範圍包含開始和結束日期，它們本身可以是年、月和日的複合體。

在這樣做的過程中，我遇到了兩個複合物件是否相同的疑問。如果我有兩個點物件都表示笛卡爾座標 (2,3)，那麼將它們視為相等是有道理的。由於其屬性的值（在本例中為其 x 和 y 座標）而相等的物件稱為值物件。